Background

Eddy-CUDA has a slice-to-volume motion correction method. It is enabled by the --mporder <int> flag and requires that slice times and multiband acceleration factor are defined.

Currently users are accessing this feature by creating their own slice-timing file and mounting it into the container, along with specifying the other options in the eddy config json file (eg #184). This is a lot of extra work and not robust if there are different slice timings in different scans.

Proposed change

The trickiest part here is figuring out what the slice timings should be if there are multiple scans being concatenated before they're sent to Eddy. If the slice timings are too different, qsiprep should detect it early and exit. We discussed that a 10ms difference in a slice's timing across scans is acceptable.

I propose we just take the slice timings from the first scan as the official slice timings sent to Eddy.

To Do

• Create a json file from the MergeDWI interface that copies slice timings from a real sidecar
• Pass the sidecar to Eddy via --json, along with --multiband_factor when mporder is in the eddy config
  - [ ] Perform a sanity check that the slice timings are similar enough that merging them makes sense

Moved to #712